fundingmanager: configurable remote max htlcs #4527
Conversation
cfromknecht
force-pushed
the
configurable-remote-max-htlcs
branch
from
13896bd
to
d0a7fea
Compare
|
How does this approach compare to limiting the number of htlcs via the htlc interceptor (may need some extension)? Htlc interceptor provides more flexibility, but I guess it doesn't allow limiting the number of incoming htlcs.
Do you have a link? |
This doesn't actually limit your exposure because the remote party can still add up to 483 HTLCs which you can't reject until after they've been added to a signed commitment. It is also more difficult to set up and operate than a config option. Users/developers that don't take the time to set this up would find themselves, knowingly or unknowingly, creating/accepting channels with the protocol maximum.
Two of the more recent works:
To be fair, this does not completely resolve either issue. But it does lessen the worst-case chain space/channel in [1] and total fees paid at a given fee rate in [2]. For example, a wide-spread uptake of |
It is also possible to implement this more dynamic limitation in |
|
Discussed offline: dynamic limitation doesn't work because you can't cancel back a locked-in htlc without cooperation from the other party. |
Roasbeef
added
config
|
Needs a rebase! |
Otherwise the fatal error message incorrectly describes what happpened.
Currenlty the maxHtlcs value is recomputed after receiving accept_channel. This works when the derivation is deterministic, howver we now allow the user to manually override this value from open_channel. As such, we must retain the chosen value in memory throughout the funding process, otherwise the initiator would revert to the deterministic derivation and the two endpoints will disagree on the correct max-htlcs value in their view of the other's policy.
This will allow users to set a custom limit for the max number of concurrent HTLCs the remote party can add to the channel.
cfromknecht
force-pushed
the
configurable-remote-max-htlcs
branch
from
d0a7fea
to
a4031f5
Compare
|
@Roasbeef rebased. default is changed to 483 so that we don't have any abrupt changes in 0.11.1, with the intention of lowering to something like 50 for 0.12 |
|
Looks good to me ✉️ |
This PR adds the ability to configure the remote
max-htlcsvalue duringchannel funding in two ways:
default-remote-max-htlcs, which sets thedefault value for both the initiator and acceptor of the funding flow.
openchanneloption,remote-max-htlcs, allowing the initiator tospecify the acceptor's
max-htlcsvalue, overridingdefault-remote-max-htlcsfor a specific channel.
The motivation for doing so is to allow node operators and wallets to limit exposure
to the maximum number of concurrent HTLCs that can be present on the commitment
at a given time. Most nodes will never truly need the capacity specified by the protocol
maximum of 483 HTLCs (in each direction). However, recent works have also shown that
lower values here can meaningfully reduce the exposure to chain fees and network
congestion during unilateral closures. As such, this provides an initial set of controls
to migrate away from using the protocol maximum by default.
NOTE: this PR does not support specifying an override value during channel acceptance.
Down the road I think it makes sense to expose this as part of the
channel_acceptorRPC.In addition to simply accepting/rejecting an incoming channel, users would be able to
specify any of the parameters passed to
openchannelas part of the response. This refactoris quite a bit larger, so we've started with the two controls listed above.